Thats now the second time I hear that ...

I want to see that in real. Can you please sent me a ".pov"-File which I can
render in tiles to see the
problems ?

I've rendered nearly all the files in the distribution incl. some animations
and I could not see any such problems till now.

Doesn't mean I do not believe you, but I want to see this.
Maybe these influences are not really important ?

c.u.
--Theo



"Peter Popov" <pet### [at] vipbg> schrieb im Newsbeitrag
news:agemlukrl7ejp242e7ce7965dfgbcka3rf@4ax.com...
> On Thu, 15 Aug 2002 06:29:50 +0200, "Theo Gottwald *"
> <The### [at] t-onlinede> wrote:
>
> >Principialy I see no other restrictions then there are for animations.
(No
> >Jittering).
>
> It's a problem in the way radiosity works. The radiosity samples are
> stored in an octree structure which is generated during pretrace and
> trace. The problem is that samples from one part of the image can
> affect another part of the image.
>
> If you render the image in parts, the octree for each client will be
> different and the resulting radiosity render will be different.
>
> One thing that I've often though of but never had the time
> experimenting with is merging radiosity data files. Since they are
> plain ASCII files with the octree data dumped, you can try merging the
> data files from all clients into one data file after the pretrace is
> finished, then let them use that file in the trace step. This has the
> drawback that the server will have to wait for all clients to complete
> pretrace, but it may make your system useable with radiosity scenes,
> which is a big plus.
>
>
> Peter Popov ICQ : 15002700
> Personal e-mail : pet### [at] vipbg
> TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message